perm filename MILLER.TO[P,JRA]1 blob
sn#547793 filedate 1980-11-30 generic text, type C, neo UTF8
COMMENT ā VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 well mark, it's another 4am session. i am tired and grumped in general, so
C00012 ENDMK
Cā;
well mark, it's another 4am session. i am tired and grumped in general, so
you get a dump of what's "grumping" me about this deal. this is meant for
your reading only (probably too "raw" for truman, and not for anyone else)
... so go away all you mail hackers...
basically, the solution is so tightly constrained that's there's no
solution. of course that's my opinion; feel free to get another. as i see
it gene's criteria are:
1 a production quality lisp
2. portable to 10, LM, and others
3. defined by dec 31
4. cost significantly less than 400k
let D be the magic lisp
3. says D must be an existing lisp; quick definitions are absurd,
particularly in theface of 1. in fact the general task of defining a
production quality lisp is a long slow process in general; particularly if
one is to attract outsiders like maclipers and/or interlispers --that's
one thing that bothered me about the proposal i drafted last may-june, and
one thing that apppealed to me about my october proposal.
existing lisps that fit 1 are maclisp and interlisp dialects. period.
standard lisp and vlisp are interesting and are possible bases for the
proposal that is mess derived, but are NOT suitable as stated (standard
lisp is portable but not production quality; similar to vlisp. in fact the
inadequacy of vlisp led me to tlc-lisp --- and tlc-lisp as it is currently
defined is notsuitable either)
superficially 1,2,3 imply that D is LM lisp, but how do you separate LM
lisp from LM? a. there's all the display stuff that makes LM LISP so nice,
and there's the 12-16K od micro code that violates the MACRO level
portable machine. (btw, all this is spelled out very politely in a paper
-- you get the "no bullshit" variety this am) and what do you port to the
10?
so what about NIL? well portability is not well defined yet. besides, as i
mentioned in the may-june proposal, i feel NIL is too baroque. in fact,
that's the whole problem with this set on constraints: they imply that
lisp technology is a nicely canned and packaaged collection of bnf
equations and documents that tells the truth. LISP IS A MESS, and my
efforts at tlc are (converging to "were") aimed specifically at finessing
the mess and establishing a decent standard without going through the
pointless bullshit meetings that the lisp standards people seem to be
attempting; unfortunately, such ventures take money, time, and people;
unfortunately, i don't have any of the above, and response this year makes
me have considerable doubts where or not another year of $5000 gross
income is worth it.... anyway, if NIL is to be a D, then buy a piece of
mit (everyone else is)
the cleanest work so far is interlisp at parc, but it suffers from as many
hacks and historical warts as the rest of them. however, given the current
constraints, it really does look like a better basis than the conpetitors.
in particular, it is maintained by collection of people whose state of
equilibrium appears somewhat more stable than the competition. (please,
sir what is lisp machine lisp today? ans: "on which machine" -- i told you
i was in a evil mode/mood) of course, then there's the cost constraint:
even transfering interlisp to the vax is estimated to take at best two
years, and maybe four (with one year down already). and that's using the
most portable of the extant lisp's (fitting 1-3). that's damn expensive.
what's to happen? well, perhaps the lisp people will sit around pissing
and moaning at each other, protecting their private dialectcal dung hills,
while the pascal people rally around the S&M standard ADA and the creative
ones ignore LISP and take to the well defined and soon ubiquitious
smalltalk. of course, the lisp people can look up occasionally and say
"... but we did that in lisp in 1960", while the five little smalltalk-80
piggies go "hee-hee-hee" all the way to the bank.
i think a lot of the probelm stems from trying to retrofit history, rather
than start over... consider scheme, for example. as an analogy, when a car
manufacturer wants a new model, they don't go get last year's models and
hack, patch, and modify to make the new issue (even chrysler doesn't do
that); they start over, saving those segments of the design that were
deemed useful and chuck the rest. unfortunately to constraints for the
magically lisp don't allow this.
what's to do with weaker constraints? first, it is presumptious folly to
assume we can spawn fully grown a "production lisp"; that must be done by
experimentation and takes time; that was the basis of my october proposal
and we all know where that led.
so the "fall back" position is to bandage a portable production system out
of the current rubble. i opt for attempting a subset i call VML that will
support an interesting part of interlisp and maclisp, and given this VML,
define a VM that is portble. of course the trick is to find a useful VML
(if one exists) --that's part of the lisp standards swamp. i may attend
that meeting if i can afford it.
...enough of this. i must get back to the proposal; i will ship you a
polite version of all this later today. be warned; it is expensive and is
predicated on the presumption that appropriate people are available now
and not "growable".
unfortunately, i feel the best course for all concerned --you, me and
lisp-- was what i proposed in october. however, considering the general
reaction to my ideas (ti is not alone) i have serious doubts about
fighting this battle at all. sorry to be in such a shitty mood, but looking
at the financial, educational and technical future does not lead to optimism.
john